home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11640 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.4 KB  |  55 lines
  1. Path: news.sinet.slb.com!usenet
  2. From: "Vinh D. Nguyen" <vnguyen@sugar-land.anadrill.slb.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Memory Leak?
  5. Date: Fri, 15 Mar 1996 08:45:04 -0600
  6. Organization: Schlumberger Anadrill
  7. Message-ID: <31498270.7661@sugar-land.anadrill.slb.com>
  8. References: <4i2tr9$q6k@newsgate.dircon.co.uk>
  9. NNTP-Posting-Host: 163.185.118.40
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Chris Pyman wrote:
  16. > 
  17. > main(int argc, char* argv[]) {
  18. >         CString s1("31-12-99");
  19. >         CString s2;
  20. > 
  21. >         s2 = s1.Mid(0,2) + s1.Mid(3,2) + s1.Mid(6,2);
  22. > 
  23. >         cout << s2;
  24. >         return 0;
  25. > }
  26. > 
  27. > Obviously the idea is to set s2 to "311299", but I would have thought
  28. > that the Mid() method creates a new CString object and returns a
  29. > reference to it, in which case what becomes of the three "temporary"
  30. > objects used to build the string in s2?  Are they just floating around
  31. > with no way to get at them, or do they get properly deleted?  And if
  32. > the latter, how does MFC manage it?
  33. > 
  34.  
  35. No, you will not experience any memory leakage as long as your CString constructor
  36. properly deallocates the buffer used to hold the characters. You are correct that
  37. the CString::Mid method returns temporary strings but these temporary strings
  38. are created on the stack (the buffers holding the actual characters are
  39. created on the heap of course) and will be destroyed properly by the time the 
  40. function exits. I am not sure when these temporary objects actually get destroyed
  41. but I imagine it would depend on the compiler. A smart compiler should recognize
  42. these objects as temporary and delete them as soon as the statement has been
  43. executed. (There is no need to keep something around that the programmer has no way
  44. to get to!) A dumb compiler would probably keep them around until the function
  45. exits. Can anyone out there enlighten me on this?
  46.  
  47. -- 
  48. --------------------------------------------------------------------------
  49. * Vinh Nguyen                                            vnguyen@slb.com *
  50. * Drilling Information Products - Senior Engineer                        *
  51. * Anadrill Schlumberger                             *
  52. * 200 Gillingham Ln.                             (713) 275-7524 (Office) *
  53. * Sugarland, TX 77478                            (713) 275-8098 (FAX)    *
  54. --------------------------------------------------------------------------
  55.